As software becomes more complex and specialized so do the testing harnesses used to verifying the software's functionality. Often a testing harness includes some basic functionality that is useful for testing a wide variety of applications. However, a testing harness can also include specialized functionality, such as functionality specific to a particular application, a class of applications, or even a particular developer. In these cases, the functionality of the testing harness has to be extended or augmented. The customization can be done through modularization and libraries, such as static or dynamic link libraries.
A major drawback to the static and dynamic link library approach is that the functionality provided in a library must be known at compile or link time. That is, the particular functionality that is to be included in the customized build of the testing harness has to be specified prior to producing the computer executable application. This places a heavy burden on the developer of the testing harness when the developer is committed to releasing customized versions of the testing harness. For example, if a testing harness developer has created a testing harness for testing internal software, the harness may include functionality that is specific to the developer and/or includes proprietary information, but the testing harness may also include functionality that of interest to third-party developers. If the testing harness developer wants to release the testing harness to third-party developers, the testing harness developer must sanitize the testing harness by creating a separate third-party build that does not include the proprietary functionality. This approach not only creates extra overhead, but it also leaves open the possibility of accidentally including the proprietary information.